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I. 


INTRODUCTION 


A.  NAVAL  POSTGRADUATE  SCHOOL  SPACE  SITUATIONAL 
AWARENESS  EFFORT 

This  thesis  discusses  Space  Situational  Awareness  (SSA),  the  feasibility  of  using 
a  CubeSat  to  enhance  space  situational  awareness,  and  the  steps  taken  to  integrate  a 
CubeSat  with  an  optical  imager  for  that  purpose.  The  author  was  the  first  student  at  the 
Naval  Postgraduate  School  (NPS)  to  work  on  this  SSA  project.  Figure  1  shows  an 
example  of  a  CubeSat  with  an  optical  imager  for  the  payload,  the  Miniature  Imaging 
Spacecraft  (MISC)  from  Pumpkin,  Inc. 


Figure  1.  Miniature  Imaging  Spacecraft,  Pumpkin  Inc. (From  [1]) 

In  early  2010,  Lawrence  Livermore  National  Laboratories  (LLNL)  proposed  a 
joint  SSA  project  with  NPS  and  Texas  A&M  University  (TAMU).  LLNL  would  develop 
an  optical  imager  for  capturing  streaks  on  a  charge  coupled  device  (CCD)  camera  from 
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light  reflected  by  satellites  in  support  of  the  Space  Telescope  for  the  Actionable 
Refinement  of  Ephemeris  (STARE)  program.  Analysis  of  these  streaks  should  permit 
improvement  of  the  orbital  ephemeris  of  the  observed  satellite.  For  this  project,  NPS  and 
TAMU  are  integrating  the  payload  with  the  spacecraft  bus.  The  payload  is  an  electro- 
optical  imager,  and  the  spacecraft  bus  is  a  Colony  II  Bus  (C2B)  from  the  Boeing 
Corporation.  Since  May  2010,  LLNL,  NPS,  and  TAMU  have  participated  in  telephone 
conferences  to  discuss  the  status  of  each  institution  and  the  work  completed,  as  well  as 
resolving  issues  that  were  encountered  and  deciding  the  best  course  of  action. 

The  C2B  is  a  3U  CubeSat.  A  1U  CubeSat  is  a  very  small  spacecraft  with  exterior 
dimensions  of  10cm  by  10cm  by  10cm.  A  2U  CubeSat  is  the  size  of  two  CubeSats,  with 
one  stacked  on  the  other,  with  the  dimensions  of  10cm  by  10cm  by  20cm.  Similarly,  a 
3U  CubeSat,  such  as  the  C2B,  is  the  size  of  three  CubeSats  stacked,  with  the  dimensions 
of  10cm  by  10cm  by  30cm.  Figure  2  shows  three  CubeSats,  starting  with  two  1U  on  the 
right,  2U  to  the  left,  and  3U  on  the  far  left. 


Figure  2.  1U,  2U,  and  3U  CubeSats  (From  [1]) 
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B. 


SPACE  SITUATIONAL  AWARENESS 


Space  situational  awareness  is  the  ability  to  maintain  and  utilize  the  knowledge  of 
all  Earth  orbiting  objects,  space  weather,  and  radio  frequency  interference,  and  how  these 
affect  our  use  of  space.  Earth  orbiting  objects  include  active  and  inactive  satellites,  spent 
rocket  bodies,  and  orbital  debris  [2],  The  United  States  currently  tracks  19,000  man¬ 
made  objects  larger  than  10cm,  including  800  active  satellites.  Each  of  these  objects 
poses  a  threat  to  active  satellites,  with  the  potential  of  destroying  the  satellite  and  causing 
even  more  debris.  Figure  3  shows  an  exaggerated  view  of  the  orbiting  objects  in  Low 
Earth  Orbit  (LEO).  The  term  space  situational  awareness  was  first  used  by  Secretary  of 
Defense  Donald  Rumsfeld  in  his  2001  report  on  space  [3]. 


Figure  3.  Artist  rendition  of  orbital  debris  in  LEO  (From  [4]) 


C.  HISTORY 

Orbital  debris  is  produced  every  time  a  satellite  is  launched  into  orbit.  Since  the 

first  artificial  satellite,  Sputnik,  was  launched  on  October  4,  1957,  the  amount  of  debris 

orbiting  the  Earth  has  steadily  increased.  Every  space  launch  creates  orbital  debris  along 

with  the  addition  of  the  active  satellite.  In  addition  to  routine  spacecraft  launches, 
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collisions  in  space  also  add  to  the  amount  of  orbital  debris.  Just  within  the  past  few 
years,  there  have  been  three  spacecraft  collisions  that  have  brought  space  situational 
awareness  to  the  forefront  of  space  related  topics. 

The  first  intentional  collision  in  recent  history  was  when  a  Chinese  Fengyun  1C 
(FY-1C)  polar-orbiting  weather  satellite,  shown  in  Figure  4,  was  intercepted  by  a  Chinese 
SC-19  missile  on  January  11,  2007.  The  relatively  high  orbital  altitude  of  the  FY-1C, 
869km,  combined  with  the  high  relative  velocity  between  the  satellite  and  missile, 
created  over  3,000  pieces  of  orbital  debris  [5],  This  impact  created  a  debris  field  that 
spans  from  as  low  as  200km  altitude  all  the  way  up  to  3,500km.  The  high  altitude  debris 
will  take  decades  to  reenter  the  Earth’s  atmosphere,  causing  potential  collision  for  as  long 
as  the  debris  remains  in  orbit.  Figure  5  shows  the  debris  field  just  five  minutes  after  the 
collision,  where  each  green  dot  represents  one  piece  of  trackable  orbital  debris  over 
10cm.  Figure  6  shows  the  current  debris  field,  where  each  red  dot  represents  the  FY-1C 
collision  debris  and  each  green  dot  represents  all  other  tracked  orbital  objects.  The  green 
line  shows  the  International  Space  Station  at  an  altitude  of  300km. 


Figure  4.  Chinese  FY-1C,  intercepted  by  SC-19,  January  11,  2007  (From  [5]) 
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Figure  5.  FY-1C  debris  field  five  minutes  after  SC- 19  impact  (From  [6]) 


Figure  6.  Current  debris  field  after  FY-1C  interception  (From  [6]) 
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The  second  intentional  spacecraft  collision  occurred  on  February  21,  2008  when  a 
United  States  Standard  Missile  III  (SM3)  intercepted  a  failing  U.S.  satellite.  Because  the 
satellite’s  orbit  had  already  decayed  to  a  low  altitude  of  240km,  the  debris  field  caused 
from  the  collision  reentered  the  Earth’s  atmosphere  within  a  month  [7], 

The  first  unintentional  collision  of  two  spacecraft  occurred  on  February  11,  2009. 
In  this  collision  a  dead  Russian  satellite,  Cosmos  2251,  collided  with  the  Iridium  33 
satellite  at  an  orbital  altitude  of  790km  [16].  This  unprecedented  collision  created  over 
500  pieces  of  orbital  debris  and  destroyed  an  active  satellite,  and  brought  space 
situational  awareness,  as  well  as  the  need  to  better  track  Earth  orbiting  objects  into 
mainstream  media. 

D.  CURRENT  SSA  ARCHITECTURE 

In  order  to  achieve  space  situational  awareness,  it  is  imperative  to  detect  objects 
orbiting  the  Earth.  Once  the  objects  are  detected,  tracked,  and  catalogued,  the  data  is 
then  used  to  predict  the  object’s  orbital  path  and  the  potential  for  collisions.  This  section 
discusses  the  current  SSA  architecture  of  the  United  States. 

The  Space  Surveillance  Network  (SSN)  uses  optical  and  radar  sensors  to  detect, 
track,  identify,  and  catalog  all  man-made  objects  orbiting  the  earth  [8].  As  of  1998,  the 
resident  space  object  (RSO)  catalog  contained  over  10,000  objects  [9].  The  SSN  tracks 
objects  in  low  earth  orbit  (LEO)  as  small  as  10cm. 

a.  Ground-based  Architecture 

The  SSN  consists  of  radar  and  electro-optical  (EO)  sensors.  The  three 

types  of  radar  sensors  are  tracking,  detection,  and  phased  array  [8].  The  tracking  radar, 

shown  in  Figure  7,  the  oldest  type  of  radar  used  by  the  SSN,  helps  predict  the  target 

object’s  trajectory.  Because  the  tracking  radar  sends  a  single  beam  of  radar  and 

physically  tracks  an  object  orbiting  the  earth  as  it  crosses  its  field  of  view,  it  is  only 

capable  of  tracking  one  object  at  a  time  and  cannot  search  for  an  object.  The  second  type 

of  radar  used  is  the  detection  radar,  which  sends  a  large  area  of  radar  energy  and  receives 

a  return  when  an  object  crosses  through  it.  The  third  type  of  radar  used  by  the  SSN  is  the 
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phased  array  radar  that  uses  thousands  of  steerable  transmit  and  receive  beams  and  can 
track  hundreds  of  targets  simultaneously.  Phased  array  radars,  shown  in  Figure  8  provide 
tremendous  capability,  but  have  extremely  high  cost  and  are  complex  to  build,  maintain, 
and  operate.  While  radar  sensors  send  out  energy  and  receive  returns  when  an  object 
intersects  the  beam,  EO  sensors  passively  gather  light  reflected  off  an  object,  forming  an 
image.  EO  sensors  can  only  collect  images  when  the  imager  is  in  the  dark  with  clear 
skies  and  when  sunlight  is  illuminating  the  target  object.  An  example  of  an  EO  sensor 
for  SSA  is  shown  in  Figure  9. 


Figure  7.  SSN  Tracking  radar,  (From  [8]) 
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Figure  8.  Phased  array  radar  (From  [8]) 


Figure  9.  Electro-Optical  sensor  for  SSA  (From  [10]) 
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The  three  main  categories  of  SSN  sensors  are  dedicated,  collateral,  and 
contributing  [8].  Dedicated  sensors  are  those  that  have  the  primary  mission  of  space 
surveillance  and  are  owned  by  Air  Force  Space  Command.  Collateral  sensors  have  a 
primary  mission  other  than  space  surveillance,  but  are  still  an  important  part  of  the  SSN. 
These  sensors  are  also  owned  by  Air  Force  Space  Command,  most  of  which  were 
initially  designed  for  missile  warning.  Finally,  contributing  sensors  provide  data  to  the 
SSN,  and  are  owned  by  private  contractors  or  other  branches  of  the  U.S.  government. 
Figure  10  shows  the  locations  of  dedicated,  collateral,  and  contributing  sensors  of  the 
space  surveillance  network. 
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Figure  10.  SSN  dedicated,  collateral,  and  contributing  sensor  locations  (From  [8]) 


b.  Space-based  Architecture 

The  first  space-based  platform  to  perform  space  surveillance  was  the 
Space-Based  Visible  (SBV)  program  [9],  SBV  was  an  EO  camera  payload  on  the 
Midcourse  Space  Experiment  (MSX)  satellite  that  launched  in  1996  into  a  900  kilometer 
altitude  orbit,  as  seen  in  Figure  11.  After  first  completing  one  year  of  technology 
demonstration,  SBV  began  contributing  to  the  SSN.  The  mission  of  SBV  was  to  gather 
metric  and  photometric  information  on  resident  space  objects  (RSO).  After  years  of 
service,  SBV  is  no  longer  functioning. 
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Figure  1 1 .  Space-Based  Visible  (SBV)  sensor  on  the  Midcourse  Space  experiment 

(MSX)  satellite  (From  [9]) 

Space  Based  Space  Surveillance  (SBSS)  is  now  conducted  with  just  one 
satellite,  SBSS  Block  10.  Shown  in  Figures  12  and  13  are  the  SBSS  Block  10  payload 
and  a  simulated  image  of  the  spacecraft,  respectively.  SBSS  Block  10,  launched  in  2010, 
improved  greatly  on  the  performance  of  SBV  [11],  Areas  of  improvement  are  sensitivity, 
capacity,  detection  probability,  and  the  time  to  detect  threats. 
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Figure  12.  SBSS  Block  10  payload  (From  [1 1]) 


Figure  13.  SBSS  Block  10  (From  [11]) 
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II.  FEASIBILITY  OF  USING  3U  CUBESAT  TO  ENHANCE 
SPACE  SITUATIONAL  AWARENESS 


The  feasibility  of  using  a  3U  to  enhance  Space  Situational  Awareness  is  addressed 
here.  The  Satellite  Toolkit  (STK)  was  used  to  run  simulations  of  the  SSA  CubeSat  with 
optical  imager  as  it  orbits  the  Earth,  taking  images  of  other  satellites  when  there  was  a 
conjunction  opportunity. 

A.  SIMULATION  CONSTRAINTS 

1.  Orbital  Parameters 

The  SSA  CubeSat  will  be  placed  into  an  orbit  by  a  launch  vehicle.  For  a 
representative  orbit,  the  STK  simulation  used  an  altitude  of  700km  above  the  surface  of 
the  Earth  at  an  inclination  of  63  degrees. 

2.  Imaging  Satellite  Constraints 

In  order  for  the  optical  imager  to  take  an  image,  the  SSA  CubeSat  must  be 
completely  in  the  Earth’s  shadow,  called  umbra,  while  the  target  satellite  must  be  in  full 
sunlight,  as  seen  in  Figure  14. 


Figure  14.  Depiction  of  umbra  and  full  sunlight  (From  [12]) 


The  STK  simulation  included  several  other  constraints  on  the  spacecraft.  The 

imager’s  field  of  view  was  taken  into  account;  however,  it  was  not  used  as  a  constraint 

because  of  the  spacecraft’s  attitude  control  system.  For  instance,  because  the  satellite  has 

the  ability  to  maintain  a  particular  attitude  while  imaging  an  object,  it  was  assumed  that 
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the  SSA  imager  is  pointed  at  the  target  satellite,  maintaining  the  requisite  sensor  pointing 
accuracy.  The  light-sensitive  optics  used  in  the  imager  can  be  damaged  by  looking  at 
bright  objects  such  as  the  sun  or  the  sun’s  reflection  on  the  Earth.  Therefore,  the  imager 
has  a  solar  exclusion  angle  of  30  degrees  and  an  Earth  exclusion  angle  of  85  degrees  to 
ensure  that  neither  bright  object  comes  into  the  field  of  view  of  the  imager.  The  solar 
exclusion  angle,  as  seen  in  Figures  15  and  16,  is  the  angle  between  the  sun  and  a  target 
satellite,  as  viewed  from  the  imaging  satellite.  For  example,  if  a  target  satellite  was 
within  the  solar  exclusion  angle,  because  the  satellite  attitude  control  system  would  be 
programmed  to  not  point  the  imaging  sensor  inside  the  exclusion  angle,  it  would  not  take 
an  image  that  particular  satellite. 


Area  of  Exclusion 


Figure  15.  Solar  exclusion  angle  (from  [12]) 
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Figure  16.  Example  of  sun  angle  and  imager  field  of  view  (From  [13]) 

Additional  physical  constraints  applied  to  the  STK  simulation  were  the  maximum 
range  and  crossing  velocity  between  the  SSA  CubeSat  and  the  target  satellite.  The 
crossing  velocity  is  the  relative  velocity  between  the  imaging  and  target  satellite.  For  the 
purposes  of  this  analysis,  the  maximum  range  for  the  useful  goal  was  chosen  to  be 
300km.  Similarly,  the  maximum  crossing  velocity  between  satellites  is  chosen  to  be 
three  kilometers  per  second,  though  useful  data  is  gained  from  a  conjunction  with 
crossing  velocity  between  satellites  of  less  than  10km  per  second.  Because  both  the 
imaging  and  target  satellite  are  in  LEO,  the  maximum  expected  crossing  velocity  is  over 
14km  per  second,  while  the  average  relative  velocity  is  between  nine  and  ten  km  per 
second  [14]. 

B.  SIMULATION  RESULTS 

Several  STK  simulations  were  run,  each  with  varying  constraints  and  parameters. 
To  get  a  representative  sample  of  one  year  in  orbit,  the  simulations  were  each  run  from 
01  January  2011  through  31  December  2011.  Propagating  satellites  for  an  entire  year  is 
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computationally  demanding  and  resource  intensive.  The  objects  used  in  STK  were 
unclassified  active  satellites  only.  This  limited  the  possible  conjunction  opportunities  by 
precluding  classified  national  systems,  as  well  as  orbital  debris  maintained  in  the  SSN 
catalog,  although  it  provided  a  good  representative  sample  of  imaging  opportunities. 

In  the  first  STK  simulation  the  maximum  range  of  the  imaging  satellite  was  set  to 
1,000km.  This  not  only  took  more  than  four  hours  to  run,  but  it  also  yielded  many 
conjunction  opportunities,  proving  that  at  least  one  conjunction  per  day  was  possible. 
The  maximum  range  was  then  decreased  from  1,000  to  100km,  yielding  fewer 
conjunction  opportunities.  The  third  simulation  included  a  maximum  range  of  300km, 
which  is  a  compromising  balance  between  minimum  range  with  few  conjunctions  and 
maximum  range  with  many  conjunction  opportunities. 

The  STK  satellite  database  was  first  filtered  to  display  only  satellites  with  an 
apogee  less  than  2,000km  in  order  to  have  a  possible  conjunction  opportunity.  To  reduce 
computation  time,  all  of  the  filtered  satellites  were  not  added  to  the  simulation  at  the 
same  time.  Eight  iterations  of  this  simulation  were  run  for  one  year,  each  with  a  portion 
of  the  filtered  satellites.  A  list  was  made  of  any  satellite  that  had  a  conjunction 
opportunity  at  least  once  during  the  year.  After  eight  iterations,  the  compiled  list  of  159 
conjunction-capable  satellites  was  used  in  another  simulation.  Table  1  shows  a 
representative  sample  of  satellites  that  produced  a  conjunction  opportunity  in  February, 
2011  at  a  range  less  than  300km. 
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SSA  imaging  opportunity 

Time  (UTCG) 

Range  (km) 

S  AUDICOMS  AT_5_3 1 1 24 

1  Feb  2011  02:20:47.902 

280.30 

UGATUSAT  35869 

1  Feb  2011  18:49:39.314 

293.18 

METEOR-M  1  35865 

2  Feb  2011  09:37:56.131 

154.42 

VO-52_28650 

2  Feb  2011  17:51:36.710 

283.07 

COROT  29678 

2  Feb  2011  23:21:01.487 

264.02 

COSMIC-3FM2  29052 

3  Feb  2011  07:01:55.423 

159.66 

T  ATI  ANA_2_3  5868 

3  Feb  2011  11:58:41.520 

109.65 

STERKH  2  35866 

3  Feb  2011  16:54:39.435 

230.96 

SLOT  B8  25416 

5  Feb  2011  12:15:22.012 

297.09 

ORBCOMMFM 1 9  254 1 5 

5  Feb  2011  22:08:12.953 

288.93 

T  ATI  AN  A_2_3  5868 

6  Feb  2011  05:49:55.932 

110.10 

THEOS  33396 

12  Feb  2011  18:15:23.278 

224.07 

THEOS  33396 

15  Feb  2011  08:49:08.670 

160.00 

THEOS  33396 

17  Feb  2011  23:22:56.082 

130.64 

SPOT  4  25260 

18  Feb  2011  09:15:26.590 

297.22 

FORMOSAT-2  28254 

19  Feb  2011  03:21:58.059 

212.41 

THEOS  33396 

20  Feb  2011  13:56:39.470 

123.10 

SPOT  4  25260 

20  Feb  2011  23:49:19.379 

267.70 

THEOS  33396 

23  Feb  2011  04:30:25.082 

146.87 

SPOT  4  25260 

23  Feb  2011  14:23:08.471 

238.77 

ORBCOMMFM05  25 1 1 7 

25  Feb  2011  11:24:50.997 

64.31 

SLOTA1251 17 

25  Feb  2011  11:24:50.997 

276.45 

ORBCOMMFM  1 6_254 1 7 

25  Feb  2011  17:59:43.564 

223.34 

THEOS  33396 

25  Feb  2011  19:04:19.795 

142.90 

SPOT  4  25260 

26  Feb  2011  04:57:03.153 

261.98 

THEOS  33396 

28  Feb  2011  09:38:14.336 

179.00 

Table  1.  Representative  list  of  satellites  with  conjunction  opportunity  at  a  range  less 

than  300km  during  February  2011 


All  159  satellites  were  entered  in  a  single  simulation,  which  was  run  in  one  month 
increments  to  determine  the  conjunction  opportunities  possible  in  a  month,  as  shown  in 
Figure  17,  where  the  cyan  orbit  track  is  the  SSA  CubeSat,  labeled  as  SSA,  and  the  dark 
blue  lines  represent  the  orbit  track  of  the  other  159  satellites. 
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Figure  17.  STK  simulation,  3D  image 

The  constraint  for  the  maximum  relative  velocity  between  the  imager  and  the 
target  satellite  is  10  kilometers  per  second,  but  less  than  three  kilometers  per  second  is 
preferable.  Since  satellites  in  LEO  are  travelling  at  roughly  seven  and  a  half  kilometers 
per  second,  the  maximum  relative  velocity  is  15  kilometers  per  second,  assuming  the  two 
satellites  are  in  similar  orbits  with  opposing  directions.  For  example,  if  the  target  satellite 
and  the  SSA  imager  are  each  travelling  seven  and  a  half  kilometers  per  second  and  have  a 

kwi  I —  kin 

crossing  angle  of  90  degrees,  the  relative  velocity  would  be  7. 5 — V2=10.6 — . 

s  s 

Therefore,  the  crossing  angle  between  the  imager  orbital  velocity  and  the  target  satellite 
orbital  velocity  should  be  less  than  90  degrees. 

Figure  18  shows  the  two  dimensional  depiction  of  both  satellites  during  a 
conjunction,  where  Rt  and  Vx  are  the  position  and  velocity  vectors  for  the  SSA  satellite, 

R2  and  V2  are  the  target  satellite’s  position  and  velocity  vectors  relative  to  the  center  of 
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the  Earth,  and  Rn  is  the  relative  position  between  the  satellites.  The  relative  velocity 
between  the  two  satellites  is  given  by  VRelative  =  V2-Vx,as  shown  in  Figure  19. 


Center  of  Earth 

Figure  1.  Satellite  position  and  velocity  vectors  used  for  calculation 

The  relative  velocity,  VRelative  ,  between  the  two  satellites  has  both  parallel  and 
perpendicular  components  to  the  line  of  sight  between  the  two  satellites.  The  line  of  sight 
vector, Rn,  is  shown  in  Figure  18,  and  is  Rn=R2-Rx.  The  parallel  component  of 

relative  velocity  is  calculated  by  taking  the  dot  product  of  the  relative  velocity  and  Rn 

[19],  as  shown  in  Equation  1.  The  perpendicular  component  of  velocity  is  what  creates 
the  relative  difference  in  position  of  the  target  satellite  that  is  imaged  as  a  streak  by  the 
CCD,  and  is  the  desired  and  constraint-driven  velocity  component.  The  perpendicular 

component  of  relative  velocity,  Vu  ,  ,  is  found  using  Equation  2  as  follows: 

r  j  ?  Perpendicular 5  b  n 

VparaM  =  \  (Equation  1) 
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(Equation  2) 


Figure  19.  Vector  geometry  used  for  calculating  relative  and  perpendicular  velocity 

An  example  of  a  conjunction  at  a  distance  of  less  than  300km  with  a  relative 
velocity  less  than  three  kilometers  per  second  was  with  the  satellite  COSMOS_2428  on 
June  5,  2011.  Cosmos_2428,  launched  on  June  29,  2007  into  an  orbit  with  an  apogee  of 
880km  and  perigee  of  850km  and  an  inclination  of  71  degrees,  is  a  Russian  electronic 
intelligence  satellite  [18],  Table  2  shows  the  position  and  velocity  of  the  two  satellites 
during  the  conjunction.  For  this  conjunction  opportunity,  the  relative  velocity  between 
the  imager  and  Cosmos_2428  was  found  to  be  1.8  kilometers  per  second.  Therefore,  this 
conjunction  should  provide  a  useful  image. 
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J2000  Position  and  Velocity 

X  (km) 

Y  (km) 

Z  (km) 

Vx  (km/sec) 

Vy  (km/sec) 

Vz  (km/sec) _ 


SSA 

COSMOS  2428 

3929.89 

4186.88 

-2672.61 

-2795.53 

-5245.29 

-5188.85 

6.24 

5.84 

1.89 

0.28 

3.71 

4.57 

Table  2.  Position  and  velocity  used  for  crossing  velocity  used  for  sample  calculation 


Once  the  tangential  component  of  relative  velocity  is  determined  to  be  less  than 
three  kilometers  per  second,  the  next  step  is  to  ensure  the  streak  imaged  by  the  CCD  will 
fit  in  the  imager’s  three  degree  field  of  view  during  the  one  second  exposure.  This 
calculation  solves  for  the  angle  subtended  by  the  satellite  streak,  where  one  side  of  the 
triangle  is  the  range  between  the  two  satellites  at  the  time  of  the  conjunction  (296km), 
and  the  other  side  is  the  1.8km  Cosmos_2428  travels  in  the  tangential  direction,  relative 
to  the  imager,  in  one  second.  The  angle  is  calculated  to  be  0.35  degrees,  using  Equation 
3,  which  is  smaller  than  the  imager’s  three  degrees  field  of  view.  As  a  result,  the  streak 
will  easily  fit  inside  the  imager’s  field  of  view. 


^sin  1 


^  1.8  km  ' 
v296 ,4km  y 


(Equation  3) 
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III.  INTEGRATING  SPACECRAFT  BUS  AND  PAYLOAD 


For  NPS  to  properly  integrate  a  payload  with  the  C2B,  it  is  important  to 
understand  both  the  payload  and  the  spacecraft  bus.  This  thesis  takes  an  initial,  overview 
look  at  both  the  bus  and  payload  to  prepare  for  their  eventual  integration.  The  space 
available  inside  the  spacecraft  for  the  payload,  the  payload  bay,  is  roughly  half  of  the 
spacecraft,  or  1.5  U,  which  is  9.75cm  x  9.75cm  x  15.0cm,  as  seen  in  Figure  20.  The 
payload  bay  must  contain  the  payload  and  all  required  interfaces. 


Figure  20.  Spacecraft  layout  and  payload  dimensions  (From  [  1 5]) 

The  two  main  components  of  a  spacecraft  are  the  bus  and  payload.  The  payload 
is  the  main  experiment  or  instrument  that  performs  the  spacecraft’s  mission.  The 
spacecraft  bus  contains  the  rest  of  the  spacecraft,  specifically  the  structure,  attitude 
determination  and  control  subsystem,  power  generation  and  storage,  and 
communications . 
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A. 


COMPONENT  INTEGRATION 


1.  Conceptual  Spacecraft  Block  Diagram 

The  C2B  provides  power  and  data  to  any  payload.  The  LLNL  payload  includes  a 
payload  processor  board,  called  the  imager  board  and  formerly  known  as  the  BC500,  and 
a  GPS  unit  (OEMV-1G).  The  C2B  communicates  directly  with  the  payload  processor 
board  and  GPS  receiver.  The  payload  processor  board  and  camera  communicate  with  the 
C2B  via  serial  data.  The  payload  processor  processes  information  from  the  camera  and 
GPS  receiver,  then  sends  information  to  the  C2B  for  storage  or  transmitting  to  the 
ground.  Figure  21  shows  the  conceptual  spacecraft  block  diagram,  created  using 
Microsoft  Visio.  The  C2B  is  shown  on  the  left..  The  payload  processor  receives  the  raw 
data  from  the  optical  imager  and  GPS  receiver,  then  processes  the  information  and 
transfers  the  data  to  the  C2B.  The  solid  lines  represent  power  distribution,  while  the 
dashed  lines  represent  data  links. 


Figure  2 1 .  Functional  spacecraft  block  diagram  of  spacecraft  bus  and  payload 
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2.  Spacecraft  Component  Connections 

After  understanding  the  functional  block  diagram  of  the  spacecraft  bus  and 
payload,  it  was  important  to  know  how  each  component  connects  with  each  other.  As 
shown  in  Figure  22,  the  C2B  provides  one  data  cable  and  one  power  cable.  The  payload, 
on  the  far  right,  has  three  connectors,  where  two  are  for  the  payload  processor  board  and 
one  is  for  the  GPS  receiver.  The  dashed  box  in  the  center  of  the  Figure  represents  the 
required  interface  between  the  C2B  and  the  payload.  By  noting  the  different  size  of  the 
connectors,  with  a  20-pin  data  connector  from  the  spacecraft,  and  both  20-pin  and  30-pin 
data  connectors  on  the  payload,  it  is  easy  to  see  the  requirement  for  a  good  interface  to 
enable  the  spacecraft  bus  and  payload  to  operate  and  communicate  with  each  other.  The 
lines  drawn  between  the  connectors  are  representative  and  may  not  be  actual  data  paths. 
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Figure  22.  Spacecraft  bus  and  payload  connectors 
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Two  methods  of  creating  the  connections  between  the  bus  and  payload  were 
evaluated.  The  first  method  requires  cutting  and  splicing  the  wires  to  create  the  required 
connections.  Since  there  are  five  cables  required  to  complete  the  integration  process, 
using  the  cut  and  spliced  wiring  procedure  was  labeled  the  penta-hamess.  The  second 
integration  method  uses  a  printed  circuit  board  (PCB)  to  connect  the  bus  and  payload. 

Creating  the  penta-hamess  requires  snipping  the  wires,  stripping  the  sheath  from 
the  wire,  and  then  soldering  the  wire  to  another  wire  to  properly  route  the  signals. 
Figures  23  through  25  show  the  author  stripping  the  snipped  wire,  labeling  the  wires,  and 
displaying  the  relative  size  of  the  wire. 


Figure  23.  Stripping  the  sheath  off  wires  of  the  20-pin  C2B  data  cable 
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Figure  24.  Labeling  the  wires  of  the  20-pin  C2B  data  cable 


Figure  25.  Demonstrating  the  small  size  of  the  wire  (only  0.255  mm  diameter)  of  the 

20-pin  C2B  data  cable  [17] 
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The  second  method  of  integrating  the  bus  and  payload  uses  a  PCB.  The  PCB 
holes  are  built  into  the  board,  allowing  the  connectors  and  cables  to  be  soldered  directly 
into  the  board.  This  creates  more  sturdy  contacts,  eliminates  the  need  to  splice  wires 
together,  and  easily  allows  varying  connector  cables  length.  The  size  of  the  PCB  is  not 
much  larger  than  the  size  of  the  connectors  themselves.  The  PCB’s  mass  is  estimated  to 
be  30  grams,  similar  to  the  mass  required  to  create  the  penta-hamess. 

After  developing  both  the  penta-hamess  and  PCB  for  integration,  this  project  is 
planning  to  move  forward  with  the  PCB  instead  of  the  penta-hamess.  Several  factors 
were  considered  when  choosing  between  the  two  integration  methods.  First,  the  small 
size  of  the  30  gauge  wire,  only  0.255  mm  diameter  [17],  makes  cutting,  stripping,  and 
splicing  difficult.  Second,  when  splicing  one  wire  from  a  connector  to  another  wire  from 
another  connector,  the  splice  must  be  soldered  to  ensure  good  connectivity.  When  the 
solder  solidifies  it  becomes  stiff,  no  longer  allowing  the  wire  to  be  flexible,  and  creates  a 
potential  weak  point  where  the  wire  can  snap  if  bent.  The  third  reason  the  PCB  was 
chosen  over  the  penta-hamess  is  because  three  connects  on  two  boards  require  power 
from  the  C2B.  With  the  penta-hamess,  all  three  connectors  would  have  to  be  powered, 
adding  to  the  complexity  of  the  integration.  With  the  PCB,  however,  power  is  distributed 
easily  to  both  boards.  The  final  and  most  critical  reason  why  the  PCB  was  chosen  over 
the  penta-hamess  is  the  requirement  for  an  active  component,  the  level  shifter,  discussed 
later,  which  requires  a  power  source  to  enable  communication  between  the  C2B  and 
payload. 

The  first  step  to  create  the  integration  board  (I-board)  was  to  determine  the 
components  that  needed  to  connect  to  the  board.  As  mentioned  previously,  there  are  two 
inputs  coming  from  the  C2B,  the  20-pin  data  cable  and  the  six-wire  power  cable. 
Therefore,  the  first  two  components  on  the  I-board  were  the  connectors  required  to  attach 
to  the  C2B  data  and  power  source.  These  two  connectors  will  be  soldered  into  the  I- 
board  so  the  associated  cables  can  plug  in  to  the  board.  The  next  three  components  that 
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need  to  be  attached  to  the  I-board  are  the  two  cables,  one  twenty-pin  and  one  thirty-pin 
for  the  payload,  as  well  as  the  GPS  20-pin  cable.  These  three  cables  will  be  soldered  into 
the  I-board. 


Before  laying  out  the  wiring  on  the  PCB  using  Altium  Designer,  a  pseudo  PCB  I- 
board  was  created  in  order  to  become  familiar,  and  alter  if  necessary,  the  layout  of  the 
PCB.  The  pseudo  PCB  was  created  using  the  3-D  modeling  programNX6.  Rectangular 
slots  were  used  for  connector  insertion  into  the  board.  Figure  26  shows  a  screenshot  of 
the  pseudo  PCB  using  NX6,  where  the  dimensions  are  2cm  by  3cm. 


Figure  26.  Screenshot  of  pseudo  PCB  created  in  NX6 


Figure  27  shows  the  PCB  I-Board  with  attached  C2B  data  and  power  connectors, 
both  payload  cables,  and  the  GPS  cable.  The  end  of  the  payload  and  GPS  cables  that  is 
not  attached  to  the  I-board  will  connect  to  the  payload  (in  the  direction  of  the  arrow 
shown  in  the  Figure). 
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Figure  27.  Pseudo  PCB  I-board  with  C2B  data  and  power  (left),  payload  cables  (right), 

and  GPS  cable  (bottom) 


Figure  28  shows  the  underside  of  the  pseudo  PCB  I-board.  The  C2B  data  and 
power  cables  are  on  the  right,  the  payload  cables  are  on  the  left,  and  the  GPS  cable  is  at 
the  bottom.  On  the  PCB,  the  pins  protruding  through  the  board  will  be  soldered  in  place. 
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Figure  28.  Underside  of  pseudo  PCB  I-board,  where  the  C2B  data  and  power  (right), 

payload  cables  (left),  and  GPS  cable  (bottom) 

It  is  extremely  important  for  the  connectors  on  the  I-board  to  be  as  secure  as 
possible.  While  the  two  cables  for  the  payload  and  the  cable  for  the  GPS  board  will  be 
soldered  directly  into  the  I-board  because  they  are  the  terminal  end  (male),  the  C2B  data 
cable  the  socket  end  (female)  cannot  be  soldered  directly  to  the  PCB.  Therefore,  a 
locking  mechanism  may  be  used  on  the  board,  as  seen  in  Figure  29.  The  two  connectors 
on  the  payload  and  the  connector  on  the  GPS  board  also  need  to  be  securely  attached, 
however,  NPS  is  not  responsible  for  the  payload  board  or  the  GPS  board.  The 
requirement  and  implementation  for  the  securing  mechanism  of  the  payload  and  GPS 
boards  needs  to  be  determined. 
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Figure  29.  Locking  Mechanism  used  on  I-board  to  connect  and  secure  C2B  data  cable 

to  PCB  (From  [20]) 

3.  Spacecraft  Bus  Emulator 

The  C2B  emulator  is  intended  to  facilitate  initial  testing  the  payload  without 
requiring  the  use  of  an  actual  spacecraft  bus,  engineering  design  unit  (EDU)  or  flight  unit, 
which  is  expensive  and  limited  in  availability.  In  addition  to  the  connectors  and  cables 
mentioned  in  the  previous  section,  laboratory  equipment  was  required  to  create  the 
emulator.  The  power  supply  chosen  was  the  Agilent  E3632A,  which  can  provide  two 
different  power  levels  as  required  by  the  payload.  The  RS422,  providing  serial 
communication  between  the  payload  and  bus,  was  purchased  from  B&B  Electronics.  The 
digital  channels  from  the  bus  provide  the  inputs  and  outputs  for  the  payload.  These 
digital  channels  are  provided  by  Measurement  Computing  Company’s  Data  Acquisition 
(DAQ)  module. 

Using  Microsoft  Visio,  a  block  diagram  of  the  C2B  emulator  was  created,  as  seen 
in  Figure  30.  The  dashed  box  on  the  left  shows  the  laboratory  equipment  used  to  provide 
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the  power  and  data.  The  two  boxes  on  the  right  of  the  figure  show  the  three  payload 
connections.  The  connections  in  the  center  of  the  diagram  provide  the  necessary 
integration  of  the  bus  and  payload,  according  to  the  current  documentation  provided  by 
LLNL.  Although  the  documentation  is  not  yet  complete,  the  integration  concept  is 
straightforward.  The  need  is  to  understand  the  bus  and  payload  well  enough  to  ensure 
signal  compatibility  and  operability. 
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Figure  30.  C2B  emulator  and  payload  integration  block  diagram 


4.  Payload  Extender 

The  payload  extender  is  used  to  connect  the  spacecraft  bus  and  payload  without 
requiring  the  payload  to  be  placed  inside  the  spacecraft.  This  allows  easier  access  to  the 
payload  for  troubleshooting  and  reduces  wear  and  tear  on  the  components.  The  payload 
extender  consists  of  cables  with  the  same  connector  ends  used  for  the  payload  and  bus 
integration.  For  instance,  instead  of  a  four  inch  cable  used  inside  the  spacecraft,  a  12 
inch  transfer  cable  is  used  to  lengthen  the  connection  to  connect  to  the  payload  outside 

the  bus.  Figure  3 1  shows  the  12  inch  transfer  cables  used  to  create  the  payload  extender. 
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Figure  3 1 .  Payload  extender  using  12  inch  transfer  cables 


B.  TESTING  COMPONENTS 

The  first  test  of  the  spacecraft  interface  simulator  was  the  serial  communications 
between  the  spacecraft  bus  and  payload.  This  test  used  the  RS422  portion  of  the  C2B 
emulator  and  the  communication  terminal  program  TeraTerm.  The  C2B  emulator  was 
connected  to  a  computer’s  communications  port  using  the  RS422,  and  the  emulated 
payload  with  RS232  was  connected  to  a  different  communications  port  on  the  same 
computer.  Using  Tera  Term,  a  message  was  sent  from  the  emulated  bus  to  the  emulated 
payload.  Initially,  the  communication  did  not  work  between  the  C2B  RS422  and  the 
payload  RS232.  The  communication  between  RS422  and  RS232  did  not  work  because 
the  two  methods  of  communication  are  incompatible  due  to  their  design.  The  RS422, 
using  two  wires  to  transmit  and  two  wires  to  receive,  uses  differential  voltage.  This 
means  that  the  RS422  needs  both  a  positive  voltage  and  a  negative  voltage  to  form  a 
binary  digit.  The  RS232,  on  the  other  hand,  uses  single  ended  output  and  input,  requiring 
only  one  wire  for  transmitting  and  one  wire  for  receiving.  This  single  ended  output  is 
achieved  using  positive  only  voltage,  using  a  low  voltage  for  a  binary  zero  and  a  higher 

voltage  for  a  binary  one.  Because  the  RS232  only  registers  positive  voltages,  it  does  not 
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interface  properly  with  the  negative  voltages  of  the  RS422.  The  solution  is  to  use  a  level 
shifter  to  allow  communications  between  the  bus’  RS422  and  payload’s  RS232. 
Requiring  the  level  shifter  necessitates  using  an  interface  PCB  vice  the  penta-hamess. 
The  level  was  designed  and  put  together  by  NPS  lab  manager  David  Rigmaiden.  Figure 
32,  also  created  by  David  Rigmaiden,  demonstrates  how  the  MAX3070E  level  shifter 
enables  communication  between  the  four  wire  RS422  and  the  two  wire  RS232.  Figure  33 
shows  the  use  of  the  level  shifter  on  a  prototype-board  required  to  facilitate  RS422  to 
RS232  communication.  Figure  34  shows  the  RS422  portion  of  the  C2B  emulator 
connected  with  two  separate  communication  ports  of  a  computer 
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Figure  32.  Schematic  of  how  the  MAX3070E  level  shifter  enables  communication 

between  RS422  and  RS232 
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Figure  33.  C2B  RS422  (left)  to  payload  RS232  (right)  using  level  shifter  (center) 
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Figure  34.  C2B  RS422  to  payload  RS232  communication  test 


After  verifying  the  level  shifter  worked  to  enable  communication  between  the 
C2B  and  the  payload,  a  preliminary  graphical  user  interface  (GUI)  was  created  by  NPS 
SSAG  Research  Associate  Jim  Homing.  This  GUI  uses  the  same  communication  ports  as 
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before,  but  includes  the  Measurement  Computing  Corporation  (MCC)  DAQ,  is 
programmed  to  emulate  the  data  provided  by  the  C2B.  Figure  35  shows  the  DAQ 
connected  to  the  GUI  via  communication  port.  In  the  GUI  window,  the  user  can  select 
the  desired  Digital  Input/Output  (DIO)  on  the  DAQ.  The  illuminated  red  light  next  to  a 
DIO  means,  that  DIO  is  being  used.  In  addition  to  enabling  and  disabling  selected  DIOs, 
the  GUI  allows  the  user  select  files  to  transfer  between  the  C2B  and  payload.  The 
received  file  is  also  saved  in  specified  locations. 
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Figure  35.  MCC  DAQ,  controlled  by  GUI,  connected  to  communication  port 


Figure  36  shows  the  GUI  for  both  the  C2B  and  the  payload,  with  none  of  the  DIO 
turned  on.  To  test  communication  between  bus  and  payload,  a  sample  code  sent  from  the 
C2B  to  the  payload,  then  from  the  payload  to  the  C2B.  In  this  case,  a  sample  text  file 
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was  sent,  as  seen  below.  Because  the  text  was  successfully  sent  and  received  from  both 
the  emulated  C2B  and  payload,  it  is  seen  in  both  GUI  screens. 
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Figure  36.  C2B  emulator  GUI  communicationg  with  emulated  payload,  not  using 

Digital  Input/Output  (DIO) 


With  the  four  DIOs  turned  off,  the  red  light  next  to  the  corresponding  wire  on  the 
DAQ  is  not  illuminated,  as  seen  in  Figure  37. 
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Figure  37.  MCC  DAQ  controlled  by  C2B  interface  GUI,  not  using  DIO 


Figure  38  shows  the  GUI  with  the  four  DIOs,  two  for  the  C2B  emulator  and  two 
for  the  payload.  This  communication  test  was  again  successful,  as  the  same  text  is  shown 
in  both  GUI  received  file  text  box.  Figure  39  shows  the  DIOs  being  used,  as  were  turned 
on  using  the  GUI  in  Figure  38. 
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Figure  38.  C2B  emulator  GUI  communicationg  with  emulated  payload,  using  DIO 
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Figure  39.  MCC  DAQ  controlled  by  C2B  interface  GUI,  using  DIO 


The  GUI  was  created  using  the  programming  language  Python.  Where  Teraterm 
is  useful  for  transferring  human  readable  files,  such  as  text  or  American  Standard  Code 
for  Information  Interchange  (ASCII)  characters,  this  GUI  allows  the  binary  formatted 
fdes.  Python  required  the  use  of  a  universal  library  to  enable  the  GUI  to  communicate 
with  the  dynamic  link  layer  (DLL)  files  of  the  DAQ,  which  is  how  the  DIOs  are 
controlled  through  the  GUI. 
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IV.  FUTURE  INTEGRATION  WORK 


As  this  is  the  first  thesis  on  this  project,  there  is  still  much  to  do  to  prepare  for  the 
scheduled  launch  in  May  2012,  as  seen  in  Table  3. 


Task 

Date 

Bus  Emulator  /  Extender 

Dec  2010 

C2B  EDU  Available 

Jan  2011 

Integrated  CAD  Model  Provided 

Jan  2011 

C2B  Flight  Hardware  Available 

Feb  2011 

Payload  EDU  Certification 

Jul 2011 

C2B  /  Payload  Flight  Unit  Acceptance 

Jul  2011 

Flight  Unit  Integration 

Nov  2011 

End-to-End  Flight  Unit  Test 

Dec  2011 

Launch  Opportunity 

May  2012 

Table  3.  Schedule  for  spacecraft  completion  and  launch 


A.  COMPLETE  C2B  EMULATOR  AND  PAYLOAD  EXTENDER 

1.  C2B  Emulator  PCB 

The  C2B  and  payload  integration  requires  the  use  of  a  PCB,  as  mentioned 
previously.  To  identify  and  correct  potential  problems,  a  prototype  board,  or  proto-board, 
is  first  created  to  test  some  of  the  desired  capabilities.  Where  the  PCB  uses  the  small 
connectors  used  in  the  actual  spacecraft,  the  proto-board  uses  slightly  larger  holes  and 
connectors,  to  ease  making  and  testing  connections.  The  proto-board  will  have  the  same 
digital  signals  and  power  inputs  to  the  payload  as  the  spacecraft,  but  in  a  more  user- 
friendly  format. 
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2.  Payload  Extender 

Once  the  C2B  emulator  is  complete,  the  payload  extender  will  be  utilized.  The 
payload  extender  uses  cables  known  as  transfer  cables.  These  transfer  cables  have  both  a 
male  and  a  female  end  that  extends  the  connector  the  length  of  the  cable.  Twelve  inch 
cables  are  used  to  facilitate  the  extender.  Since  the  payload  extenders  have  been  fitted  to 
the  C2B  emulator,  it  will  be  tested  again  for  signal  strength  to  ensure  the  extender  does 
not  alter  the  signal  level. 

B.  TEST  C2B  EMULATOR 

Once  the  C2B  emulator  is  complete,  it  must  be  tested.  The  signals  coming  from 
the  DAQ  digital  input  can  be  tested  for  continuity.  The  GUI  will  be  used  to  facilitate  the 
testing.  More  programming  is  also  required  for  the  C2B  emulator  to  recognize  particular 
message  types  and  save  the  file  to  a  specified  location  for  that  message  type.  For 
instance,  if  the  payload  sends  the  C2B  binary  formatted  combined  image  data,  the  C2B 
must  recognize  what  type  of  file  is  being  received,  and  then  store  it  in  its  corresponding 
location.  Also,  the  C2B  emulator  must  be  programmed  to  capture  and  log  data  to  a  file. 
Sample  data  packets  will  be  provided  and  used  to  transmit  actual  commands  to  the 
payload.  Similarly,  data  packets  will  be  sent  from  the  payload  to  the  C2B  emulator  to 
test  its  ability  to  recognize  different  types  of  files  and  save  the  data  in  the  proper  location. 

Because  the  serial  data  connection  already  tested  is  the  main  source  of 
communication  between  the  bus  and  payload,  the  rest  of  the  DIOs  from  the  C2B  are  not 
used  by  the  payload.  Even  though  payload  will  not  use  the  other  C2B  DIOs,  the  inputs 
will  still  be  connected  to  create  a  higher  fidelity  C2B  emulator,  and  allow  flexibility  in 
the  additional  tests  that  can  be  conducted. 

C.  COMPLETE  AND  TEST  PAYLOAD  EMULATOR 

Just  as  the  C2B  emulator  will  aid  in  testing  and  integration,  the  payload  emulator 
will  provide  the  capability  to  overcome  potential  payload  integration  obstacles.  By  using 
another  proto-board,  the  payload  emulator  will  not  be  difficult  to  build.  Having  both  a 

C2B  emulator  and  a  payload  emulator  enables  the  project  to  have  an  entire  emulated 
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satellite  on  the  workbench.  This  greatly  increases  the  testability  and  educational  value. 
This  allows  NPS  the  ability  to  anticipate  and  eliminate  any  unforeseen  difficulties. 
Additionally,  with  the  C2B  emulator,  testing  can  be  done  on  the  payload.  Similarly,  with 
the  payload  emulator,  the  spacecraft  bus  can  be  tested,  as  well  as  the  communications 
between  the  bus  and  payload. 

D.  GROUND  STATION  PREPARATIONS 

The  concept  of  operations  has  to  be  developed  in  order  for  NPS  to  operate  the 
ground  station  for  the  satellite.  To  accomplish,  the  list  of  commands,  command  names, 
and  command  descriptions  needs  to  be  provided  by  LLNL.  An  example  of  the  required 
concept  of  operations  is  the  routine  commands  sent  to  the  satellite,  such  as  specific  tasks 
to  be  completed  at  required  intervals. 
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V.  CONCLUSION 


This  thesis  chronicles  the  background,  development,  and  initial  steps  to 
integrating  an  optical  imager  provided  by  Lawrence  Livermore  National  Laboratories 
with  a  3U  CubeSat,  the  Boeing  Colony  II  Bus,  as  part  of  the  joint  Space  Situational 
Awareness  project  STARE  with  NPS  and  Texas  A&M  University.  The  imager  captures 
time-lapse  streaks  of  other  satellites.  Analyzing  these  streaks  will  provide  data  to 
improve  the  orbital  ephemeris  of  the  imaged  satellite. 

Work  done  in  support  of  STARE  includes  performing  STK  analysis  proving  the 
project’s  feasibility,  developing  the  PCB  and  penta-hamess  for  integrating  the  C2B  and 
payload,  making  the  decision  to  move  forward  with  the  PCB  instead  of  the  penta-hamess, 
creating  the  communications  link,  including  the  active  component  level  shifter,  between 
the  bus  and  payload,  and  programming  a  GUI  to  communicate  with  the  DAQ  in  order  to 
use  specific  DIOs,  emulating  the  C2B.  Future  work  includes  completing  and  testing  the 
C2B  emulator,  laying  out  the  integration  PCB,  and  developing  the  ground  station  concept 
of  operations. 
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